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FOREWORD 


Each  DCASR  headquarters  is  responsible  for  the  Mechanization  of  Contract 
Administration  Services  (MOCAS).  This  is  an  automated  data  system  which 
provides  management  and  operational  data  on  delivery  schedules,  shipments, 
contractual  changes  and  disbursements  to  contractors.  At  each  DCASR, 
information  is  extracted  from  contractual  documents  by  data  input  clerks  and 
entered  into  the  MOCAS  system.  One  recent  enhancement  of  MOCAS  is  the 
development  of  an  on-line  capability  for  data  input,  which  is  replacing  a  batch 
method  of  data  input.  This  on-line  capability  was  the  subject  of  this  study, 
which  was  sponsored  by  the  DLA  Office  of  Telecommunications  and  Information 
Systems  and  performed  by  the  DLA  Operations  Research  and  Economic  Analysis 
Office. 

—The  first  purpose  of  this  study  was  to  develop  standards  or  threshold  values 
for  system  response  times  for  the  on-line  input  of  contractual  documents.  Such 
standards  would  be  the  maximum  allowable  values  of  response  times  which  would 
permit  the  backlog  of  documents  awaiting  input  to  be  kept  within  an  acceptable 
range.  By  establishing  standards  for  response  time,  it  is  then  possible  for 
the  DL/i.  Systems  Automation  Center  to  determine  the  level  of  ADP  capacity 
necessary  to  meet  the  needs  of  the  functional  users  of  the  new  on-line  system. 
Jhfs  is  far  preferable  to  sizing  ADP  requirements  based  on,  for  example,  an 
/  arbitrary  level  of  CPU  utilization. 


The  second  purpose  of  this  study  was  to  measure  the  data  input  productivity 
improvement  associated  with  the  new  on-line  system.  ( — It  is  the  conclusion  of 
the  study  that  the  number  of  documents  per  day  that'  atKinput  clerk  can  process 
on-line  will  increase  by  roughly  15  percent  over  the  batciJ  input  method.  This 
productivity  improvement  can  be  used  to  reduce  personnel  Requirements  while 
maintaining  backlog  performance,  or  else  it  can  be  used  to  reduce  backlog  size 
if  personnel  requirements  are  kept  at  their  present  levels. 
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I. 


INTRODUCTION 


A.  Contract  Administration  Services 

One  of  the  most  important  missions  of  the  Defense  Logistics  Agency  (DLA) 
is  the  administration  of  defense  contracts  for  the  military  services, 
DtA,  and  NASA.  This  function  is  performed  by  DLA's  Defense  Contract 
Administration  Services  (DCAS).  The  United  States  has  been  divided  into 
nine  geographic  regions,  with  each  region  having  a  headquarters  office 
(DCASR).  Assignment  of  a  contract  to  a  DCASR  is  determined  by  the 
geographic  location  of  the  contractor  involved. 

Each  DCASR  headquarters  is  responsible  for  the  Mechanization  of  Contract 
Administration  Services  (MOCAS).  This  is  an  automated  data  system  which 
provides  management  and  operational  data  on  delivery  schedules, 
shipments,  contractual  changes  and  disbursements  to  contractors.  The 
military  services,  other  agencies,  and  contractors  are  continually 
sending  contractual  and  delivery  documents  to  the  DCASR.  Contractual 
documents  include  new  contracts  and  contract  modifications;  delivery 
documents  are  called  DD250s.  In  addition,  corrections  to  the 
contractual  and  delivery  documents  are  also  continually  required.  At 
each  DCASR,  then,  information  is  extracted  from  each  of  these  documents 
by  data  input  clerks  and  entered  into  the  MOCAS  system. 

MOCAS  has  been  and  will  continue  to  be  upgraded  under  a  phased  program. 
One  recent  enhancement  is  the  development  of  an  on-line  capability  for 
the  data  input  of  contractual  and  delivery  documents.  This  on-line 
capability  replaces  an  earlier  batch  operation  and  provides  for  (1)  on¬ 
line  input  and  validation  of  data,  (2)  immediate  updating  of  the  MOCAS 
data  base,  and  (3)  immediate  access  of  contract  and  delivery  status  and 
information  to  the  buying  organization  and  other  managers  through  on¬ 
line  queries. 

DCASR-Atlanta  was  selected  as  the  first  site  for  the  on-line  enhancement 
to  MOCAS  (known  as  MOCAS  Phase  II).  Atlanta  was  selected  as  the 
prototype  installation  because  it  is  a  relatively  small  DCASR  (in  terms 
of  number  of  contracts  managed).  DCASR-Cleveland,  being  a  "medium"  size 
DCASR,  was  selected  as  the  second  site  for  MOCAS  Phase  II.  As  of  this 
writing,  Atlanta  and  Cleveland  have  already  been  equipped  with  Phase  II; 
the  largest  DCASRs  (Los  Angeles,  Boston  and  Philadelphia)  will  be 
equipped  last  due  to  concern  about  sufficient  ADP  capacity  to 
accommodate  the  new  system. 


MOCAS  Data  Input 


The  actual  process  of  data  input  is  somewhat  complex.  Basically,  the 
hardcopy  documents  are  sent  to  the  DCASR  by  mail,  and  mail  clerks  then 
collect  and  sort  the  documents.  Contractual  documents  are  then  given  to 
control  clerks  who  enter  the  documents  into  the  daily  backlogs  of  new 
contracts  and  contract  modifications.  The  documents  then  are  further 
sorted  and  given  to  the  data  input  clerks.  The  input  clerks  collect 
pertinent  information  from  these  documents  and  enter  this  information 
into  the  MOCAS  Data  Base  Management  System  (DBMS).  This  is  a  menu- 
driven  system,  and  the  input  of  a  document  requires  the  selection  of 


several  screens.  Moreover,  the  input  clerks  must  typically  input  the 
appropriate  information  at  each  screen  and  then  wait  for  the  system  to 
respond  (this  is  called  a  screen-to-screen  response)  and  display  the 
next  screen.  After  all  information  from  the  document  is  input  into  the 
system,  the  last  step  is  a  system  validation  and  update  (called  a 
summary  edit)  of  the  MOCAS  data  base.  This  last  step  involves  a 
somewhat  longer  system  response  time.  At  this  point,  the  document  is 
removed  from  the  daily  backlog  of  documents  awaiting  data  input. 

The  input  clerks  must  also  make  corrections  to  the  contract  data  in  the 
MOCAS  data  base.  A  correction  does  not  involve  a  legal  change  to  the 
contract  like  a  contract  modification,  but  rather  is  simply  a  fix  to  an 
identified  mistake  or  typographical  error.  Corrections  still  require 
several  screens  of  input  followed  by  a  summary  edit  and  make  up  a 
significant  portion  of  the  input  clerks'  workload. 

The  new  contract  and  contract  modification  processing  also  include 
documents  that  are  sent  by  electronic  transmission  from  the  buying 
organization  directly  into  the  MOCAS  data  base.  This  process  is  known 
as  the  Military  Standard  Contract  Administration  Procedures  (MILSCAP). 
This  electronic  transmission  does  not  include  all  of  the  needed 
information,  and  the  buying  organization  must  therefore  send  a  follow-up 
hardcopy  of  the  MILSCAP  contract  or  modification  to  the  DCASR.  When  the 
follow-up  hardcopy  arrives  at  the  DCASR,  data  input  clerks  then  enter 
the  remaining  information  from  the  document  into  the  system  using 
correction  mode.  In  the  case  of  Atlanta,  separate  MILSCAP  clerks  are 
used  for  this  data  input;  in  Cleveland,  the  hardcopy  data  input  clerks 
also  enter  the  MILSCAP  corrections.  In  either  case,  the  MILSCAP 
correction  must  also  be  included  in  the  input  clerks'  workload. 

C*  Study  Objectives 

In  June  of  1984,  the  DLA  Headquarters  Office  of  Telecommunications  and 
Information  Systems  (DLA-Z)  requested  that  the  DLA  Operations  Research 
and  Economic  Analysis  Office  (DLA-LO)  perform  a  study  on  data  input  for 
MOCAS  Phase  II.  The  study  would  serve  two  distinct  but  related 
purposes.  The  first  purpose  of  the  study  would  be  to  establish 
standards  or  threshold  values  for  system  response  times  (both  screen-to- 
screen  and  summary  edit).  The  standards  for  system  response  times,  if 
achieved,  would  mean  that  the  size  of  the  backlog  of  documents  awaiting 
input  would  not  be  unacceptably  high.  This  provided  DLA-Z  the  criteria 
to  determine  the  level  of  ADP  capacity  necessary  to  meet  the  needs  of 
the  functional  users  of  the  new  MOCAS  Phase  II  system.  This  is  far 
preferable  to  sizing  ADP  requirements  based  on,  for  example,  an 
arbitrary  level  of  CPU  utilization.  The  second  purpose  of  the  study 
would  be  to  measure  the  benefits  of  the  new  on-line  (Phase  II)  system, 
in  terms  of  lower  document  backlogs  and/or  reduced  requirements  for  data 
input  clerks,  relative  to  the  old  batch  (Phase  I)  system.  This  report 
documents  the  final  results  of  the  analysis  completed  for  Atlanta, 
Cleveland,  and  the  large  DCASRs. 

D.  Scope 


This  study  includes  a  preliminary  assessment  of  staffing  levels  for  data 


input  clerks  under  MOCAS  Phase  II.  This  assessment  is  only  for  the 
purpose  of  measuring  the  data  input  productivity  improvement  of  Phase  II 
relative  to  the  previous  Phase  I  system.  The  actual  and  official 
staffing  level  will  be  determined  by  each  regional  Office  of  Comptroller 
and  will  be  reviewed  by  the  DLA  Headquarters  Office  of  Comptroller. 


II. 


TECHNICAL  APPROACH 


A.  General  Methodology 

The  general  approach  in  this  study  was  to  develop  a  simulation  model  of 
the  data  input  process.  It  was  necessary  to  resort  to  simulation  due  to 
the  extreme  complexity  and  variability  of  the  process.  The  number  of 
documents  that  arrive  on  any  given  day  is  quite  variable,  as  is  the 
number  of  transactions  (i.e.,  screen  inputs)  for  each  document,  the 
clerk  input  time  for  each  transaction,  and  the  system  response  time 
after  each  transaction.  Each  of  these  factors  is  modeled  by  probability 
distributions;  the  model  uses  random  numbers  and  Monte  Carlo  techniques 
to  simulate  the  data  input  of  contractual  documents.  This  model  was 
developed  in  the  SLAM  simulation  language. 

In  essence,  data  input  is  modeled  as  a  queueing  situation,  where  the 
documents  are  waiting  for  input  into  the  system,  causing  a  backlog  of 
new  contracts  and  contract  modifications.  The  DCASRs  do  not  enter 
contract  corrections  into  the  daily  backlogs  but  rather  simply  input  the 
corrections  directly  into  the  data  base.  For  this  reason,  the 
simulation  model  does  not  keep  track  of  the  number  of  corrections 
awaiting  input.  However,  the  workload  associated  with  corrections  is 
included  in  the  simulation  model.  The  inputs  to  the  model  include 
parameter  values  (e.g.,  mean  and  standard  deviation)  for  the  number  of 
documents  per  day  for  each  document  type,  the  transactions  (screens)  per 
document  for  each  document  type,  the  number  of  data  input  clerks,  the 
clerk  input  time  per  transaction,  the  screen-to-screen  response  time, 
and  the  summary  edit  response  time.  The  outputs  of  the  model  include 
the  average  backlog  size  for  new  contracts  and  contract  modifications. 


The  simulation  model  is  restricted  in  scope  to  the  data  input  of 
hardcopy  documents.  There  is  no  explicit  modeling  of  the  MILSCAP 
process  in  the  simulation  model.  However,  the  MILSCAP  corrections  are 
included  in  the  data  input  workload  like  the  other  corrections. 

B.  Data  Collection 


Considerable  effort  went  into  the  data  collection  used  to  develop 
factors  for  the  simulation  model.  This  effort  was  accomplished  in 
Atlanta  and  Cleveland  by  reviewing  local  procedure  documents  on  data 
input,  by  interviewing  the  input  clerks  and  their  management,  by 
personal  observation  of  the  data  input  process,  and  by  use  of  on-line 
queries  into  the  MOCAS  data  base.  This  was  done  to  develop  the  general 
structure  of  the  model,  as  well  as  the  detailed  factors.  In  addition, 
chi-square,  goodness  of  fit  tests  were  used  to  determine  the  best 
probability  distributions  to  model  the  various  tasks  and  steps  in  the 
data  input  process. 


To  obtain  workload  information  on  each  DCASR,  the  DLA  Systems  Automation 
Center  developed  a  program  to  extract  actual  Phase  I  experience  and 
convert  it  to  a  detailed  projection  of  Phase  II  workload.  This  program 
not  only  provides  top-level  workload  information  like  new  contracts  per 
day,  but  also  provides  very  detailed  information  such  as  the  average 
number  of  line  items  per  new  contract.  This  detailed  information  was 
necessary  to  calculate  the  number  of  screen  inputs  associated  with  each 
document. 

Finally,  the  current  staffing  levels  for  input  clerks  at  each  DCASR  were 
obtained  from  each  region.  This  included  a  count  of  both  authorized 
positions  and  actual  clerks  on  hand.  The  regions  also  provided 
information  on  the  size  of  document  backlogs  under  the  current  MOCAS 
Phase  I  system. 


C.  Simulation  Model  Description 

The  model  simulates  the  daily  data  input  process  (weekends  are 
excluded).  Each  simulated  day  begins  with  the  arrival  of  contractual 
documents  to  the  mail  room.  For  each  day,  the  model  simulates  the  number 
of  new  contracts,  contract  modifications,  and  corrections.  Although 
there  is  no  backlog  criteria  for  corrections,  they  are  an  important 
part  of  the  daily  workload  for  the  input  clerks.  In  the  model,  the 
documents  are  then  delayed  for  4  hours  to  account  for  the  time  until  the 
documents  are  given  to  the  control  clerks.  Following  that,  the  new 
contracts  and  modifications  are  delayed  an  additional  2.5  hours  to 
account  for  the  control  clerk  tasks  of  reviewing  the  documents  and 
entering  them  into  the  MOCAS  backlog.  Also,  in  the  model,  there  are  two 
possible  snags  that  can  possibly  hold  up  the  input  of  documents  to  the 
system.  The  first  problem  might  occur  when  contracts  are  being 
transferred  in  from  another  DCASR.  If  the  document  is  not  provided  with 
the  proper  certification  of  funds,  then  the  document  will  (in  certain 
circumstances)  simply  have  to  wait  in  backlog  until  the  proper 
certification  can  be  obtained.  The  other  possible  problem  occurs  when 
there  is  some  internal  inconsistency  in  the  contract  or  modification. 
This  must  be  resolved  by  further  clarification  from  the  buying 
organization;  this  problem  is  called  a  1716  discrepancy.  Either  of 
these  two  problems  will  impact  the  average  backlog  size  and  the  average 
processing  time  since  the  final  input  into  the  system  is  delayed 
(perhaps  for  several  weeks)  until  the  problem  is  resolved.  In  any 
event,  the  model  assumes  that  after  the  control  clerk  review,  assuming 
no  problems,  the  actual  data  input  will  not  start  until  the  following 
morning. 

The  data  input  clerks  are  treated  as  constrained  resources  in  the 
simulation  model.  Current  staffing  levels  were  used  as  inputs  to  the 
model,  except  that  they  were  reduced  by  18%  to  account  for  leave, 
illness,  etcetera.  Clerks  are  assumed  to  be  available  for  on-line  input 
for  6.5  hours  per  day.  For  each  document,  the  model  simulates  the  clerk 
input  time  for  each  transaction  (screen).  Nine  representative  clerks  in 
DCASR- At  1 anta  (3  above  average,  3  average,  and  3  below  average)  were 
used  to  develop  a  sample  of  clerk  input  times;  this  sample  was  used  to 
develop  the  factors  used  to  simulate  clerk  input  time.  After  each  clerk 
transaction,  the  model  simulates  the  screen-to-screen  response  time. 


Finally,  the  model  simulates  the  last  clerk  input  time,  followed  by  the 
summary  edit  response  time. 

The  model  also  simulates  whether  or  not  the  summary  edit  process  detects 
any  inconsistencies  in  the  data  that  are  input  from  the  document.  If  a 
document  receives  an  unsuccessful  summary  edit  message,  then  the  input 
clerk  must  make  an  additional  transaction  to  adjust  the  data.  After 
this  adjustment  is  made,  the  summary  edit  process  continues  until  a 
successful  summary  edit  message  is  eventually  received.  At  this  point 
the  document  is  removed  from  the  backlog  of  documents  awaiting  data 
input. 

The  model  assumes  that  after  the  successful  summary  edit  response,  the 
clerk  will  read  and  study  the  next  document  awaiting  input.  In  the  case 
of  modifications,  it  may  also  be  necessary  to  review  the  information 
currently  in  the  MOCAS  data  base  through  the  use  of  on-line  inquiries. 
When  the  review  of  the  next  document  is  complete,  the  clerk  starts  the 
input  of  the  document,  and  the  cycle  of  clerk  input  times  and  response 
times  starts  all  over. 

The  most  important  output  of  the  simulation  model  is  the  size  of  the 
document  backlog.  This  backlog  size  is  the  critical  factor  for  the 
remainder  of  this  report.  The  backlog  size  is  usually  measured  in  days' 
receipts  and  not  as  an  absolute  number  of  documents.  For  example,  if  a 
DCASR  typically  received  200  documents  per  day,  then  a  backlog  of  400 
documents  would  be  described  as  two  days'  receipts. 

D.  Simulation  Model  Validation 

A  significant  part  of  this  study  was  spent  on  adjusting  and  fine-tuning 
the  simulation  model  until  the  simulation  model  output  compared 
favorably  with  actual  operational  experience  for  MOCAS  Phase  II.  This 
was  accomplished  primarily  with  backlog  experience  at  DCASR-Atl anta 
since  (at  the  time  of  this  analysis)  only  Atlanta  had  sufficient 
experience  with  the  new  system  for  the  input  clerks  to  achieve  a 
reasonable  (mature)  level  of  proficiency.  A  comparison  of  simulated 
backlog  experience  with  actual  backlog  experience  is  shown  in  Table  1. 
The  backlog  includes  both  hardcopy  contracts  and  modifications;  the 
backlog  size  is  shown  in  both  number  of  documents  and  also  in  days' 
receipts. 

Both  simulated  and  actual  backlog  experience  are  quite  high  due  to  an 
insufficient  number  of  input  clerks.  DCASR-Atl anta  has  a  total  of  18 
authorized  positions  for  data  input  clerks  (this  includes  hardcopy  input 
clerks  and  MILSCAP  clerks  but  excludes  review  clerks,  lead  clerks  and 
supervisors).  However,  the  actual  number  of  on-board  clerks  during  May 
and  June  1985  was  only  11.  The  7  vacancies  were  due  to  high  turnover  of 
personnel  and  problems  in  filling  vacancies.  The  simulation  model  was 
also  used  to  project  what  would  happen  to  backlog  size  with  an  arbitrary 
increase  of  3  additional  clerks;  the  result  is  shown  in  the  last  entry 
in  Table  1  and  is  labeled  "Get  Well." 


TABLE  1 


Backlog  of 

Hardcopy  Contracts  and 

DCASR- ATLANTA 

Modifications 

Documents 

Days'  Receipt- 

Simulated 

Mean 

843 

4.7 

Standard  Deviation 

186 

1.0 

Actual  (May-June  1985) 

Mean 

868 

4.8 

Standard  Deviation 

168 

0.9 

Simulated  ("Get  Well") 

Mean 

355 

2.0 

Standard  Deviation 

162 

0.9 
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Integration  with  DSAC  Model  in 


The  first  major  task  of  the  project  was  to  establish  response  time  goals 
for  MOCAS  Phase  II.  In  the  case  of  Atlanta,  the  system  was  already 
operational  when  the  study  was  initiated.  The  major  accomplishment  of 
the  study  was  to  verify  that  the  current  response  times  were  adequate, 
and  to  attribute  the  high  backlogs  to  an  insufficient  number  of  input 
clerks.  In  the  case  of  Cleveland,  response  time  goals  were  established 
for  the  initial  environmental  testing  of  the  new  system.  Problems  with 
high  response  times  during  this  testing  led  to  the  decision  to  upgrade 
the  processor  at  Cleveland  from  an  Amdahl  V7C  to  a  V8. 

In  the  case  of  the  larger  DCASRs,  the  project  sponsor  (DLA-Z)  needed  to 
determine  response  time  goals  (and  associated  computer  hardware 
requirements)  much  earlier  than  any  actual  environmental  testing.  This 
was  because  of  the  possibility  that  the  larger  DCASRs  might  require 
totally  new  processors  (like  an  Amdahl  5850  class  mainframe)  instead  of 
upgrades  to  their  current  processors.  A  requirement  to  obtain  new 
processors  would  have  considerable  impact  on  the  Phase  II  implementation 
schedule  due  to  the  lengthy  lead-times.  To  meet  this  need,  it  became 
necessary  to  integrate  the  functional  data  input  modeling  being 
performed  by  DLA-LO  with  the  computer  resource  modeling  being  performed 
by  the  DLA  Systems  Automation  Center  (DSAC).  The  DSAC  modeling  deals 
with  transaction  (enter-key  depression)  volumes  and  CPU  time  per 
transaction,  and  provides  a  projection  of  what  CPU  utilization  and 
response  times  will  be  at  each  DCASR.  By  integrating  the  two  modeling 
efforts,  it  then  became  possible  for  DLA-LO  to  use  its  simulation  model 
to  establish  response  time  goals  for  the  large  DCASRs  and  then  provide 
these  goals  to  DSAC  to  determine  the  computer  hardware  required  to 
achieve  them. 

This  communication  between  the  two  models  also  helped  in  measuring  the 
productivity  improvement  of  MOCAS  Phase  II,  which  was  the  second  major 
task  of  this  project.  Specifically,  once  DSAC  determined  the  computer 
hardware,  the  DSAC  model  could  then  be  used  to  project  what  the  response 
times  would  actually  be  at  a  given  DCASR.  The  DSAC  projected  response 
times,  of  course,  would  always  be  less  than  the  response  time  standards 
established  in  the  first  part  of  this  project.  These  projected  response 
times,  in  turn,  were  used  as  inputs  to  the  DLA-LO  simulation  model  to 
predict  the  impact  of  Phase  II  on  backlog  size  and  personnel 
requirements.  The  specific  results  for  both  aspects  of  this  study  are 
described  in  the  next  two  sections. 


III.  RESPONSE  TIME  GOALS  FOR  MOCAS  PHASE  II 


A.  Criteria  for  Document  Backloas 


The  first  major  task  of  this  project  was  to  establish  standards  or 
threshold  values  for  system  response  time.  The  approach  taken  in  this 
study  was  to  define  the  standards  for  response  times  as  the  maximum 
allowable  values  consistent  with  document  backlogs  being  within  an 
acceptable  range.  It  therefore  became  necessary  to  define  specific 
limits  on  backlog  size. 


SIMULA  TED  WEEKL  Y  BA  CKL  OGS 
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therefore,  the  90th  percentile  is  2.9  days’  receipts  and  is  shown  by  the 
straight  horizontal  line  labeled  "90th  Percentile." 


Similar  results  were  derived  for  Los  Angeles  and  Philadelphia.  The 
threshold  values  for  system  response  times  were  also  found  to  be  6.0 
seconds  (screen-to-screen)  and  68  seconds  (summary  edit)  for  both 
regions.  The  only  difference  in  the  results  was  that  in  Boston's  case 
the  2  days'  receipts  average  criteria  was  exceeded  first  with  increasing 
response  time,  but  for  Los  Angeles  and  Philadelphia  the  3  days'  receipts 
90%  limit  was  exceeded  first.  In  any  case,  the  range  of  acceptable 
response  times  provided  to  DSAC  were  3.1  to  6.0  seconds  for  screen-to- 
screen,  and  35  to  68  seconds  for  summary  edit.  The  lower  value  for  each 
range  is  actual  current  experience  at  DCASR-C1  eve  land  and  was  provided 
simply  for  perspective. 

C.  Results  of  DSAC  Modeling 

With  these  response  time  goals  established,  the  DSAC  model  described 
earlier  was  run  for  each  of  the  large  DCASRs.  The  most  recent  results 
(as  of  the  time  of  this  writing)  indicate  that  DCASR-Boston  can 
accommodate  MOCAS  Phase  II  on  an  Amdahl  V8,  but  that  DCASR-Philadelphia 
will  require  an  Amdahl  5850  class  computer,  and  that  DCASR-Los  Angeles 
will  require  an  Amdahl  5860  class  computer.  These  results,  however, 
only  apply  to  the  short-run  implementation  of  Phase  II;  it  is  probable, 
with  the  addition  of  other  future  on-line  systems  and  with  growth  in  the 
number  of  contracts  administered  by  the  DCASRs,  that  all  large  DCASRs 
may  eventually  require  even  more  powerful  processors. 

After  determining  the  hardware  requirements  for  each  DCASR,  DSAC  also 
provided  to  DLA-LO  specific  estimates  of  what  system  response  times  will 
be  at  each  region.  These  estimates  were  used  in  the  second  task  of  this 
project,  which  was  to  model  the  impact  of  MOCAS  Phase  II  on  backlog  size 
and  personnel  requirements.  These  results  are  described  in  the  next 
section. 

IV.  DCASR  DATA  INPUT  WORKLOAD  ANALYSIS 

A.  Measuring  Data  Input  Productivity 

In  establishing  response  time  standards  as  described  earlier,  the  number 
of  input  clerks  was  kept  fixed  at  current  levels  while  response  times 
were  increased  until  backlog  size  reached  specified  criteria.  For 
measuring  the  improved  productivity  associated  with  MOCAS  Phase  II,  the 
simulation  model  was  used  in  a  somewhat  different  way.  System  response 
times  were  kept  fixed  at  the  DSAC  projections  for  each  region,  and  the 
simulation  model  was  run  with  decreasing  numbers  of  input  clerks.  Also, 
rather  than  using  the  2  days'  receipts  (average)  and  3  days'  receipts 
(90th  percentile)  criteria,  the  simulated  backlog  size  was  compared  to 
the  actual  Phase  I  backlog  experience  for  each  of  the  large  DCASRs. 

B.  Results  for  DCASR-Los  Angeles 

The  results  of  this  analysis  for  Los  Angeles  can  be  seen  in  the 
"stacked-bar"  chart  in  Figure  2,  which  graphically  portrays  the  size  of 


SIMULATED  DOCUMENT  BACKLOGS 
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Average  [  \  ]  90th  F3ercentile 


the  combined  document  backlog  as  a  function  of  the  number  of  input 
clerks.  Each  bar  represents  a  simulation  with  a  different  number  of 
data  input  clerks.  The  bar  on  the  far  left,  for  example,  is  labeled 
100%,  meaning  100%  of  the  current  Phase  I  staffing  level  at  Los  Angeles. 
This  is  relative  to  the  actual  number  of  clerks  on-hand  and  not 
positions  authorized.  This  was  done  to  make  a  valid  comparison  between 
the  simulated  backlog  size  and  the  actual  Phase  I  backlog  experience 
being  achieved  by  the  clerks  on-hand. 

The  lower  level  of  each  stacked  bar  represents  the  average  size  of  the 
simulated  document  backlog.  The  upper  level  of  each  stacked  bar 
represents  the  90th  percentile  of  the  simulated  backlogs.  Also,  the 
simulated  backlog  performance  can  also  be  compared  to  the  actual  Phase  I 
backlog  performance  at  Los  Angeles.  The  actual  Phase  I  average  backlog 
size  is  2.7  days'  receipts,  which  is  represented  in  the  figure  by  the 
solid  line.  The  actual  90th  percentile  of  the  Phase  I  backlogs  is  3.2 
days'  receipts,  which  is  represented  in  the  figure  by  the  dashed  line. 

The  conclusion  drawn  from  this  analysis  indicates  the  implementation  of 
MOCAS  Phase  II  will  provide  roughly  a  15%  productivity  improvement  which 
can  be  channeled  in  one  of  two  directions.  Phase  II  has  a  potential  to 
reduce  the  data  input  staff  by  15%  and  maintain  backlog  performance 
roughly  at  present  levels,  or  else  to  reduce  the  average  backlog  size  by 
1  days'  receipts  if  the  staffing  level  is  maintained  at  the  current 
number  of  input  clerks. 


Summary  of  Results  for  the  Large  DCASRs 


Similar  results  were  obtained  for  Boston,  Philadelphia  and  also 
Cleveland,  by  decreasing  the  number  of  input  clerks  until  the  simulated 
backlog  size  reached  roughly  the  same  level  as  the  actual  Phase  I 
backlogs.  This  occurred  in  all  cases  at  an  85%  staffing  level,  meaning 
a  reduction  of  15%. 


These  results  are  summarized  in  Table  2,  which  shows  the  estimated  data 
input  productivity  for  each  of  the  regions  under  MOCAS  Phase  II.  The 
first  three  columns  refer  to  numbers  of  input  clerks  at  each  region. 
The  first  column  is  the  number  of  authorized  positions  for  data  input 
clerks.  These  numbers  were  never  used  in  any  of  the  simulations,  but 
are  displayed  simply  for  information.  The  second  column  represents  the 
actual  number  of  clerks  on-hand,  and  the  third  column  called  "Available" 
represents  the  adjusted  number  of  clerks  after  accounting  for  leave  and 
illness  by  an  18%  reduction.  It  is  this  third  number  which  was  actually 
used  in  the  simulation  model.  All  cases  are  shown  for  two  staffing 
levels.  "100%  Staffing"  refers  to  present  Phase  I  levels,  and  "  85% 
Staffing"  refers  to  a  15%  reduction  in  input  clerks.  This  represents 
the  point  where  backlog  performance  is  maintained  roughly  at  Phase  I 
levels.  The  fourth  column  is  the  number  of  hardcopy  documents 
(contracts  and  modifications)  received  by  each  region  per  day,  which  of 
course  is  independent  of  the  staffing  level  for  input  clerks.  The  fifth 
column  shows  the  documents  processed  by  available  clerk  per  days  for 
each  staffing  level.  For  the  case  of  "100%  Staffing"  the  number 
represents  the  data  input  productivity  under  Phase  II  should  the  region 
elect  to  use  the  productivity  improvement  to  reduce  backlogs  and  not 
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personnel  requirements.  For  the  case  of  ”85%  Staffing”,  the  number 
represents  the  data  input  productivity  under  Phase  II  should  the  regions 
elect  to  use  the  productivity  improvement  to  reduce  personnel 
requirements  and  not  backlogs. 

Two  additional  observations  are  appropriate  about  the  productivity 
figures  shown  in  Table  2.  First,  there  are  considerable  differences 
between  some  regions.  This  is  due  to  differences  in  the  nature  of  the 
region  workload,  such  as  the  average  number  of  screen  inputs  per 
document  or  the  number  of  corrections  processed  per  region  per  day. 
Second,  the  projection  under  Cleveland  for  the  case  of  "85%  Staffing" 
shows  a  productivity  of  14.9  documents  per  available  clerk  per  day. 
Actual  experience  at  Cleveland  has  been  somewhat  less  than  this  until 
recently.  From  the  period  from  June  until  August  1985,  shortly  after 
the  initial  operational  activation  of  Phase  II,  the  data  input  clerks 
were  only  processing  12.7  documents  per  available  clerk  per  day.  This 
probably  is  due  to  an  initial  "learning  curve"  effect  associated  with 
the  new  system.  During  the  month  of  November,  roughly  six  months  after 
the  transition  to  Phase  II,  the  data  input  clerks  were  processing  14.5 
documents  per  clerk  per  day,  which  is  much  closer  to  the  14.9  figure 
predicted  by  the  simulation  model.  Therefore,  these  projections  for 
data  input  productivity  will  probably  not  be  experienced  during  the 
initial  transition  to  Phase  II  at  the  large  DCASRs,  and  it  will  probably 
take  a  period  of  roughly  six  months  before  the  input  clerks  reach  the 
predicted  proficiency. 

D.  Projections  for  Other  DCASRs 

When  running  the  simulation  model  for  the  large  DCASRs,  it  was  found 
that  there  were  considerable  differences  between  regions  in  the  absolute 
number  of  documents  processed  per  clerk  per  day.  However,  in  the 
relative  comparison  of  Phase  I  to  Phase  II  data  input,  there  was  a 
fairly  consistent  pattern  of  a  15%  improvement  for  Phase  II.  This  was 
found  in  simulations  of  the  large  DCASRs  and  also  in  actual  operational 
experience  at  DCASR-Cleveland.  If  it  is  reasonable  to  assume  that  there 
would  be  a  similar  improvement  for  the  other  regions,  it  is  then 
possible  to  project  their  data  input  capacity  under  Phase  II  by  applying 
the  15%  improvement  factor  to  their  actual  Phase  I  data  input 
productivity.  This  was  done  for  New  York,  Dallas,  St.  Louis,  and 
Chicago.  The  results  are  shown  in  Table  3.  The  numbers  are  not 
available  for  Atlanta  because  it  was  already  operational  under  Phase  II 
well  before  this  project  was  initiated. 

V.  CONCLUSIONS 


The  data  input  simulation  model  was  used  to  establish  standards  for 
system  response  times  for  MOCAS  Phase  II.  Screen-to-screen  response 
time  should  not  exceed  6.0  seconds,  and  summary  edit  response  time 
should  not  exceed  68  seconds.  Achieving  these  standards  means  that  the 
backlog  of  documents  awaiting  data  input  will  be  within  acceptable 
limits.  The  standards  were  provided  to  the  DLA  System  Automation  Center 
to  determine  MOCAS  Phase  II  processor  requirements. 


14 


The  data  input  simulation  model  was  also  used  to  estimate  the 
productivity  improvement  associated  with  MOCAS  Phase  II.  The 
implementation  of  MOCAS  Phase  II  will  provide  roughly  a  15%  productivity 
improvement  for  data  input.  Phase  II  has  a  potential  to  reduce  the 
requirements  for  input  clerks  by  15%  while  maintaining  backlog 
performance  at  present  levels,  or  else  it  can  reduce  backlog  size  by 
roughly  1  days'  receipts  if  the  number  of  input  clerks  is  maintained  at 
present  levels. 

VI.  RECOMMENDATIONS 

The  purpose  of  this  analysis  was  to  estimate  the  productivity 
improvement  for  data  input  under  MOCAS  Phase  II.  This  was  accomplished, 
in  part,  by  making  a  preliminary  assessment  of  staffing  levels  for  data 
input  clerks  operating  in  the  new  on-line  environment.  However,  each 
regional  Office  of  Comptroller  should  wait  for  a  period  of  at  least  six 
months  after  Phase  II  implementation  prior  to  taking  any  action  to 
reduce  the  number  of  data  input  clerks.  This  is  because  roughly  a  six 
month  "learning  curve"  period  is  necessary  for  the  data  input  clerks  to 
achieve  full  proficiency  with  the  new  on-line  system.  Moreover,  by 
waiting  at  least  six  months  after  implementation,  each  region  will  also 
have  a  significant  measurement  of  operational  data  input  productivity  to 
further  validate  the  findings  of  this  study  (i.e.,  the  15%  productivity 
improvement).  The  actual  degree  of  personnel  reduction  will  also  depend 
on  each  region's  priorities  between  backlog  reduction  and  personnel 
reduction.  Finally,  it  is  noted  that  any  personnel  reduction  can  easily 
be  accommodated  on  an  attrition  basis  due  to  the  high  turnover  of  data 
input  clerks. 

This  study  has  provided  significant  benefits  by  integrating  the 
functional  modeling  (performed  by  DLA-LO)  with  the  hardware  modeling 
(performed  by  DSAC).  This  way,  the  functional  modeling  established 
performance  levels  to  meet  the  needs  of  the  functional  users;  the 
hardware  modeling  could  then  determine  the  level  of  required  ADP 
capacity  to  achieve  the  established  performance  levels.  It  is 
recommended  that  similar  joint  efforts  be  performed  for  future  on-line 
systems  (such  as  the  Financial  Redesign  or  the  Contract  Management 
Improvements).  Such  joint  efforts  should  be  initiated  early  to  allow 
the  functional  modeling  to  assist  in  any  design  trades  and  in  assessing 
the  costs  and  benefits  of  new  on-line  systems.  To  support  any  future 
efforts,  documentation  (including  the  source  code  and  the  SLAM  network 
diagram)  on  the  simulation  model  used  in  this  study  will  be  retained  in- 
house  in  DLA-LO,  although  it  is  probable  that  the  model  would  require 
considerable  revision  before  it  could  be  used  to  model  any  other  on-line 
system. 


